On Security, Exploratorium, and Phishing
Table of Contents
If you don’t know what the Exploratorium is, I highly recommend you take a trip to San Francisco and include it in your list of places to see. Today, when I saw a blog post come up with their name in it, I didn’t expect a story about email phishing, but there it was.
The interesting part was this:
The address of this webpage had been disguised in the link using a URL shortener, which IT reverse engineered with a URL expander in order to run a virus scan. The page appeared clean; its only apparent intention was to collect passwords. This webpage was being hosted on another server, this one at a server farm in Texas.
It’s not unheard of phishing links hiding behind URL shorteners, but what’s interesting is that with some of the modern technologies, there is an added layer of complexity, and not the good kind of complexity, that is being offloaded on the end-user. And as we know, with the less-technical users, that produces bad results.
First, read this story from Vice Motherboard. Look over the screenshots. Anything out of the ordinary stand out? Notice that one of the URLs listed is pointing to an AMP page.
If you don’t know what AMP is, it stands for Accelerated Mobile Pages, a project led by Google to load content much faster on mobile devices. You can read more about it on the official “How It Works” page.
So what’s the problem? Well in this case, AMP acts like a CDN for specially designed content. Effectively, it will be fetched from Google’s servers (read more about AMP caching). If you read through the AMP spec, you will realize that anyone can create AMP pages, and therefore, end up with an URL like this for their page:
Let’s set the Chrome test mode to iPhone 6 (can do so through the inspector/developer console) and load up the page:
Alright, so we get the green lock here. For a while, users have been conditioned to look at the URL bar and the green lock, so that’s exactly what they got here - a seemingly legit domain. Granted, AMP pages also show the domain from which the content is originally fetched, but that is easy to ignore, especially for, cough* less technical users *cough.
Let’s now open this page on mobile:
Again, URL bar shows google.com, so this must be Google.
Here is another problem though - while Google is working on adding anti-phishing measures, such as using your account picture, it’s easy to mis-use the service through Google’s own log in endpoint:
https://accounts.google.com/ServiceLogin?service=mail&continue=
This takes the user to the log in page, and post-login, redirects the user to the URL declared in the continue parameter. You can’t just put any domain in there, since it will actually require a google.com location. But guess what? You can just put an AMP page in there, and it will work:
Now you see the problem? In this inception/triple-pseudo-redirect scenario, the user can assume that they start with Google and end up on a malicious page through the auth pipeline.
Compound that with the fact that once an email is compromised, other recipients might assume that inbound mail coming from that account is safe (it’s their friend/family, after all, and they shared a document with them).
What can you do to mitigate that? #
First, use a password manager. LastPass is free, 1Password is affordable. The good thing about password managers, other than the fact that they allow you to generate strong, random and long passwords, is the fact that they support auto-fill. If all of a sudden your password is not automatically filled into a field - that’s a red flag and you are likely outside the boundaries of a legit domain.
Second, add two-factor authentication to all accounts that support it (and most modern services do). Spend $10-$15 and get yourself a YubiKey. GitHub, Google, WordPress and many others support the physical two-factor key.
Third, if you don’t expect a document, file, photo, video or anything else shared with you, chances are the email is a phishing attempt. Either confirm with the recipient that they actually shared something with you or trash the email altogether.
Fourth, do not reuse your passwords. Even with two-factor auth on, your password can be compromised through a phishing attack. It will likely be of little impact to the 2FA-protected account, but you should automatically assume that the password will be tried against other services that you might be signed up for. If you re-used the password and a service didn’t have 2FA enabled, you’re in for a very bad time.